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Intelligent Assistance without Artificial Intelligence 

CM E. Kaiser 1 
and 

Pater it Feflar 

ABSTRACT^®*** Saa dtatributad, mutt-osar software tog In—rin g arrvironmant that bahavaa aa 
an InMIgent assistant Smle prassnts a fUatass anvironmant', darivaa and transforms data to 
ahaftar usara from antarlng radundant information, automatically tnvokas programming tools, and 
ao dv aty p s rt ici pa taa in the softwara develop m ent and maintananoa process. Unftke other total- 
Igant aaais tan ts, SmM la not a ruia-basad anvironmant: Is knowledge of software objects and the 
progr a m mi ng procass is hardcoded into the anvironmant Wa daserfoa Smsje’s functionality and 
sa p ta fo how we achieved this functionaaty without raiianoa on aitifidal Intaiganoa tachnology.^- 

\ 

11ntroduction 

In 1973, Wtnograd discuss ad Ms drtam of an Intofflgcnt assistant for programmers [29]. Mors 
rsosntly, artificial Intelligence' researchers have sxtended pro g ramming languages and environ¬ 
ments (pdmarty Lisp environments) wth knowledge about tha ratal lonshlps among program units 
(26) and the rules governing the software development process (3,1,22] In an attempt to turn the 
dream into raaBty. The reauting systems support 'exploratory programming' by an individual 
progr a mmar very we« (21], but they do not provide the assistance necessary to manage large- 
scale development and maintenance. However, as Al projects, such as 'expert systems', have 
become larger and commerdaRy viable, researchers have turned their efforts towards developing 
this kind of assistance [11,18], and we believe they will produce exceflent results. 

' ! ' ll:> 

In the meantime, I is posable to buBd production-quality software engineering environments that 
provide seemingly Inteffigeni assistance without requiring new breakthroughs in Al research. 
There it already (at least) one such system—the'Software Management and Incremental Lan¬ 
guage Edfting system (Smile)— that provides seemingly intelligent, interactive support for teams 
of software developers and maintainsr». Smile does not use artificial Intelligence techniques; ft is 
not even written In Lisp. Smile was written in C and runs on Unix™. 

Although Smile is several years old, It has not been discussed in the literature, except in ack¬ 
nowledgements by researchers who used it to develop their own systems. Smile was developed 
by one of the authors, starting In 1979, originally as a tool for developing research prototypes tor 
the Gandait project [16]; It has been used extensively by both authors and by many others since 
1980. Svrle has been reded on by the Gandait and Gnome [7] projects at CMU and by the 
tnscape project [17] at AT&T Bell Labs; ft has been distributed to at least forty sites. Smile 


’This paper was wri t ten whls Dr. Kaiser was a Visiting Computer SetenSst at ha 9oriwara En g irt — ri n g Institute 
Ca rn egi e Melton Univarsity, Pittsburgh, PA. 
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pas— the crucial test of supporting to own maintenance. The purpose of this paptr ia to 
praaant tha goal* of Smle and explain how they wart achieved. 

Tha original, high-level goals of Smrje wara at folowa. 

• To hide tha ffia system and tha operating system from the users. Smu presents a 
Heists environment'; that is, Smie exposes to users only to tha logical structure of 
•ta target software system. Tha normal at amative is for users to deal with the 
ohysfca* storage of tha software In tarns of cfirectories and flies, which often do not 
correspond nicely to the logical structure. 

• To shelter the users from the tedious task of maintaining redundant Information. 

8mhje requires to users to enter each Kern of Information only once; k automatically 
transforms the data at needed by tools. Smile derives necessary information that 
can be calculated from the data supplied by users. 

• To automate invocation of tools at appropriate points. Smile assists the users by 
automatically performing trivial software development activities such as calling grep, 

Int, cc, make, and other Unix utilities [12] with the appropriate arguments at ap¬ 
propriate times. In some cases, the tool Is invoked as soon as Its Input is ready; in 
other cases, the tool is not called until its results are required, such as to answer a 
user query or to provide input to another tool. Smile hides the particularities of Unix 
and presents a uniform programming model different from the model Imposed by 
Unix. 

• To actively participate in the software development and maintenance process. Smile 
is an interactive system, and all programming activities take place within the environ¬ 
ment m addition to calculating auxiliary Information and automatically Invoking tools, 

Smile anticipates the consequences of user actions and automatically presents ap¬ 
propriate warning messages. 

• To be eufflJently robust and reliable for supporting relatively large academic 
development projects. It automatically recovers from inconsistent states after user- 
initiated aborts and machino crashes; It also stores Information redundantly to sup¬ 
port recovery from disk errors or Its own bugs. 

Al of these goals have been achieved. Smile maintains source code, object code and other 
software development information In a database mapped onto the Unix file system. Knowledge 
of software objects and a model of the software development process are hardcoded Into Smile’s 
commands. Smile incorporates a large collection of Unix utilities, plus several special tools 
developed aa part of the Gandalt research. Smile has supported the simultaneous activities of at 
least seven programmers, and the largest software system developed and maintained in Smile 
has approximately 61,000 lines of source code [13]. 

The following sections present the goals and achievements of Smile in more detail. Section 2 
explains Smile’s external architecture. Section 3 describes how Smile assists individual program¬ 
mers, while Section 4 describes the facilities oriented towards projects involving many program¬ 
mers and long lifetimes. Section 5 discusses Smile's Implementation and current status Section 
6 compares Smile to other software engineering environments. We conclude by summarizing the 
significance of Smilf as an example of intelligent assistance without artificial Intelligence. 
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2 Architecture 


Smu k Intended for um by smal teams of programmers (5 to 20) devetoping and maintaining 
medtonvstze software systems (10,900 to 250,000 Hnts of source code) written in C, taking 
maximum advantage of the Unix tie system and utilities. 

2.1 QC 

GC (Gandaf C) (28) is an enhancement of C that lists the typrs of formal parameters within the 
a rg u ment 1st (as in Pascal) and provides a module interconnection language (MIL). The MIL 
defines modules consisting cf four types of source code objects (called ferns): procedures, 
va ria b le s, types, and macros. Each module has an import 1st indicating the Rems required from 
other modules and an export 1st Unseating the Rems accessbie to other modules. GC was 
adopted by the GandaV project tor al implementation efforts. Smile supports GC, but automati- 
cafy transforms source and header ffles horn standard C to GC and vfce versa as needed to 
import existing source code and to take advantage of C-spedfic programming tools. Throughout 
the rest of this paper, we mean "GC a when we say "C". 


22 Databases 

Smile maintains alt information about a software system in a database similar to the ‘objectbases’ 
of more recently developed programming environments [2,15]. Each object has several at¬ 
tributes. representing auxiliary information, and is typed, enabling Smile to provide object- 
oriented commands that apply type-specific tools. 

A database consists of one or more ‘projects’, each representing a distinct software system. 
Most databases contain exactly one project, so we say database’ and project* interchangeably. 
A project contains a number of ‘modules’ corresponding to GC modules. Each module contains a 
set of procedures, a set of variables, a set of type definitions, a set of macros, < fist of import 
Rems, and a fist of export Items, as Illustrated in Figure 1. The source text of procedures, vari¬ 
ables, types, and macros are written in GC. Each module and Rem is attributed with status 
information, such as whether or not it has been complied since R was last modified. Modules also 
contain object code, but this is never explicitly visible to users. 

2J3 User Interface 

Smile's user Interface is script-oriented, and does not take advantage of windows or menus. 2 
However, some tools included in Smile, e.g., screen-oriented editors, behave differently for bit¬ 
mapped screens than for dumb terminals. 


*The workstation implementations of San do support windows. In particular, a usar can modify a database in one 
w indow while browsing through tha database in a saoond, read-only window; saa Section 5. 
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Figure 1: Database of Software Objects 


Tha user interface is friendly* and in tides on-Rne help facBttos. It is rot necessary to remember 
ether commands or arguments. The .«sec can type a carriage-return after entering any part of the 
command Hne, and Smle w«1 prompt, one at a time, for remaining arguments: each prompt 
Indicates a defaut value baaed on the user's most recent activities, and the user types a carriage- 
return to accept this defaut. if the user types *7* at any point, Smile lists the currently valid 
alemativee according to the user's context. If the user instead enters “help', then Smile explains 
the selected command and ts argument. The user can also ht the interrupt key to any prompt to 
abort the current command. Smile permits the user to abbreviate commands and arguments of 
commands to the shortest unambiguous form, and prompts with the possfcle choices If an ab¬ 
breviation is ambiguous. 


3 Programming Assistance 

Smile assists individual's in writing programs, it maintains C source code, object code, and the 
status of these objects in Its database, and automatically performs menial development activities. 
For example, It warns the programmer of the implications of changing the specifications of source 
code Rems, and R automatically recompiles after changes. 
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3.1 Browsing 

Smle he*pe the user navigate through a aoP vert system. The user sotects a particular 
module—the user's focus—which is then Ind tea ted in Smile's top-level prompt. Smile assumes 
that further commands refer to this module and Is cements untl a dWerent module Is selected. 

Browsing is object-oriented, In the sense that Smle automatically invokes the appropriate viewing 
tool according to the type or the selected object. For C source code, this Is normally a screen- 
oriented text editor; tn earlier version of Smile also provided a syntax-directed editor. Although 
Sm&e assumes ait commands are with respect to the current focus, I can shift focus automat 1- 
caRy as the need arises. For example, If the user asks to visit an Rem that is not in the current 
module but is in some othar module, Smle changes the focus before Invoking the appropriate 
viewer tool 

Smle also supports genera) searches. A query can apply to an individual Rem, a module, or the 
entire database and Smile can further filter the results of queries to display only Rems of a par¬ 
ticular type (import item, procedure, variable, etc.) or only items that match some pattern. Pattern 
matching can be applied to the name of an Item or to its source text, and a search can be applied 
to either the definition or usage of Rems, or Smle can generate a fuR cross-reference table. The 
results of queries are displayed on the screen in the form of a transcript, which can be scrolled if 
Smle is run from within a text editor that supports user shells. Smile can also direct Rs answers 
to an external file or a printer. Smile remembers past activities on a user-by-user basis; this 
supports, for example, a special option for the printer to spool only those Rems that have changed 
since last printed by the particular user. 

3£ Editing 

Sm&e creates and deletes modules and Rems within modules. If the user asks to remove an 
Rem that is In another module, Smle requests confirmation before automatically changing focus 
to the other module to carry out the command. Thus, Smle is forgiving of minor user errors. The 
add command requires the type of the new Rem; If this Is not given, Smle prompts for the 
missing argument. Smle Invokes the type-specific tool, and the fow-leve< commands provided by 
the tool are used to construct the content of the Rem. If the user enters a command to write, 
save, save-and-exR, etc., then the new Rem is stored In the database; H the user tslls the tool to 
abort or exR (without saving), etc., Smile aborts the original add command. Smle does this by 
monkoring the tool; no changes to the tools themselves are required. 

Similarly, an existing Rem can be added or removed from the imports or exports list of the current 
module. When a new Rem is created, Smile automatically asks the user whether or not R should 
be added to the exports list. When an Rem is removed from the exports, Smile warns the user R R 
is imported by other modules and requests confirmation; if confirmation is given, R automatically 
removes these imports as well. When a user tries to delete an existing Rem, Smle reminds the 
user R R is exported and requests confirmation before removing the corresponding Rem from the 
export list. 
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The umt can make changes to terns through the edit and change commands; Smile invokes the 
appropriate editing tool Edit restricts the user to making local changes to the body of an item, 
whereas change allows die user to make changes to both the specification and the body, wh«ch 
may have side effects on other terns. For example, edit invokes the editor tool only on the body 
of a C procedure; if me tool supports multiple windows, then the header of the procedure is 
(flepiayed for reference in another, read-only window. In the case of a C variable, edit permits 
the user tu modify the initialization, tut not the actual declaration. The edit command does not 
apply to types and macros, because any modification can affect usages. 

Sometimes changing the specification of an Rem has implications beyond those anticipated by 
the user. Therefore, Smile always Informs the user of potential problems before the damage Is 
done. When the user selects the change command, Smile queries Its databaso to find aR the 
other Items that may be affected by the proposed change and informs the user of the extent of 
this change, in terms of how many other Rems might subsequently have to be modified to main¬ 
tain consistency; it displays the actual dependencies on request. The user can abort or go ahead 
w*h the change with fun knowledge of the Implications. 

3J3 Error Detection end Error Reporting 

After a user adds, removes, or modifies an item, SMLE supplies raq?id feedback regarding static 
semantic errors. The semantic analysis is applied only to the changed item rather than to other 
Rems affected by the change. Smle propagates ths change by updating the status information 
for dependent Rems. If the user requests it. Smile submits these for analysis; this is explained in 
the following section. 

The analysis is performed in a background process, so tnat tlie user does not have to wait for the 
tool to complete before continuing other activities. When processing completes, all error or warn¬ 
ing messages are saved as an attrfcute of the current module (the focus), and the prompt is 
changed to Indicate the errors. The usei can ignore the errors, or ask Smile to display the 
messages; thus, Smile separates error detection from error reporting. Both the messages and 
the visual cue in the prompt remain until the user edits the offending item, so the user does not 
need to remember the particular errors or even the fact that there are errors within the particular 
module. It is less intrusive to indicate errors by appending a notice to the prompt than to display 
the errors themselves. An earlier version of Smile dumped all the error messages on the user’s 
screen as soon as the tool completed. This behavior was judged unacceptable because it inter¬ 
rupted the user's activities; the user was forced to read the messages then and remember them, 
because they were not stored. 


3.4 Bookkeeping 

Smo£ maintains status information for each item. For example, each C Rem has a status field 
that indicates whether or not its static semantic analysis is up to date, whether the analysis was 
successful, or whether analysis is in progress in the background. Smile maintains the correct 
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value lor the status field. Furthermore, Sole automatically propagates changes to Items by 
updating the status field of other Items that might be affected by the change. The user can 
examine the status information for any Rem or tfisplay all items with a particular status. A user 
might use this Information, for example, to request re-analysis of a particular Rem or al Kerns 
affected by a change or to look for Rems that still have errors and need correction. 

Smile performs code generation by compiling at the granularity of a module. Therefore, R main¬ 
tains a status field for each module indicating whether or not Rs object code is up to date, or being 
generated in the background. After compiling a module, Smile indicates the resulting status in 
this status field. Smile invalidates generated code by setting the status field accordingly under 
any one of several conditions: 

• a new Rem is added to the module; 

• an existing Rem is moved between modules, removed, edited or changed; 

• an Rem is added to or removed from the import Hst, and this Rem is actually 
referenced by an Rem of the module; 

• an exported Hem is changed, and this Rem is imported into another module, where R 
is actually referenced by an Rem in the importing module. 

3J5 Code Generation and Linking 

Smile recompiles modules and relinks the system as needed. X. recognizes several aRemative 
notions of ‘as needed'. There is a tradeoff between recompiling immediately after a Rem of a 
module changes and delaying until the user requests system execution: Late recompilation re¬ 
quires the user to waR, but early recompilation may be wasted ekie to further changes to the same 
module; R also affects response time after each change. An earlier version of Smile automatically 
recompiled as soon as an Rem changed, but recompiled only the Rem rather than the entire 
module. This was changed because the time and space overhead was unacceptable. The 
processing performed by the compilation too* after every modification led to slower response due 
to the cycles taken by the background job. Space was a problem because a separate object code 
file was generated for each Rem. Smile now compiles an entire module rather than individual 
Rems: This optimization was done wfthout affecting the interaction wRh the user. 

Smile automatically generates a makefile, including the appropriate command lines, and invokes 
make to construct an executable system. If a file name is given as an argument, the executable 
code is placed in this file; otherwise, standard Unix practice is followed and the output goes to the 
"a.out” file in the current working directory. 

3.6 Modes 

Modes permR the user to control and adapt Smile's behavior. Users can set modes explicitly with 
a comnwtd or implicitly in their Smile profiles. Every mode has a type and a defauR value. The 
boolean Autocompilation mode permits the user to indicate to Smile whether R should temporarily 
refrain from automatically carrying out analysis and code generation. This is a desirable feature 
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when the user starts making major changes to the application. Another boolean mode related to 
comp*a3on indicates w nether or not ttie compiler should generate more elaborate debugging 
Information. The Verbose mode indicates the level ot verbosity of Stairs warnings and sugges¬ 
tions. 

Somes modes are used to tailor Smile lo a particular operating environment. CMU mode permits 
Smis to take advantage of some special CMU utilities. Home mode defines Smile's home direc¬ 
tory in the local tfU system, and Print mode names the local tool for spooling to the printer. Smile 
is also tailored by the search paths and other environment variables defined in the user's Unix 
profile. 

4 Development end Maintenance Assistance 

Smhje assists software teams with their long-term development and maintenance activities. It 
coordinates simultaneous activities by multiple users, encourages reuse of existing code, and 
logs source code changes. 

4.1 Reservations 

Smile prevents multiple users from modifying the same modulo at the same time by requiring the 
user to reserve a module before making changes to the module. If a user tries to modify a 
component of a module that is net reserved, Smile explains that reservation is necessary. Only 
one user can reserve a module at a time. If another user attempts to reserve a previously 
reserved module, Smile informs the user about who has reserved the module; users can also 
query reservation status explicitly. 

Smile helps users avoid making Incompattole changes. If a user tries to change the specification 
of an exported Item, Smile checks to make sure that that all the modules that import this item are 
also reserved by the same user. It not. Smile informs the user of their reservation status. 

4.2 Experimental Databases 

Reservations are always made with respect to a private workspace called an experimental 
database. Rgura 2 shows the relationship between experimental databases and the public 
database, which contains the baseline version of the software system. The modules in the public 
database are available to a'l members ot the software team, while the contents of an experimen¬ 
tal diabase are private to Its owner. An experimental database is a logical copy of the public 
database; Smile employs a copy-on-write strategy to conserve space. Only modules reserved in 
the current experimental database can be modified. Additional modules can be reserved at any 
time, provided they are not already reserved by another user. Smile automatically prelinks non- 
reserved modules (in a background process) to improve the response time of system generation. 

When a user completes a set ot changes, the user gives either the update or deposit command 
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Figure a Experimental and PuMc Databases 

lo return alt the reserve* module* to lha puttie database. l^xtata retalrw th* reservation*, ao the 
user can make further changes, wNW deposit ramov a f » reservations. In athar casa. Smu s 
makaa tha change* MliM to the real of the *oftwa.e taam by replacing the previous version* 
m tha pubic daiabas# with tha changed modula* from tha axpanmantai databata. Stout parmits 
uaor* to back out of a proposed changa by ralaaalng tha currant raaarvatlona. ao othar uaara can 
raaarva thaaa module* m tholr original Kota. 

At tha bagm nl ng of an updata or a d apot tl , Stout check* tha rtatue of al raaervad lama to 
anaura that thay hava baan analyzed and compflad aucoa July, without any arrora. ifthtraara 
Inoonalatanciaa, Smhji aoon* tha command; othanMaa, Smlc lock* tha public database wM* R 
oopiaa tha modfflad objact* back Into tha pubic database. Thu*, updata and dapoalt bahava aa 
transaction* with raapact to tha pubHc databaaa. 

4JS Tranaactlona 

Evary 8tou command a a transaction, m tha aanaa that R a Imposstol# to apply a second 
command within tha *ama databaaa unit tha flrat command terminates. 3 Background processing 
la ooordlnatad m auch a way that Ra raauita ara i xx>rdad wlhout conflicting with tha transaction 
modal. An tartar version of Stoii savad Is Inttmaf atata on disk aftar aach transaction m order 
to raoord tha change* I k a fab-safe manner. TWa lad to poor responsiveness whan there were 
five or more almultanaoua uaera In a tlma-*harlng environment (on a VAX 1 * 780) and was 



*1n *>• n»o+jt««lon tmpwmeotiSon* ot 9wu, • uwr can mu unutWcwd pert* ot * datataM In a raad-cmly «*rv*rv» 
• Infl i i rt on; Jtoctiofl 5 . 
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dhoonMnu«d. 4 Currently. Smile uvm Mate after the number of traneaettone Indicated by the 


Checkpoint mode, and always save* state before and after commands that cause major changes, 
such as change, update, and deposit. A user can select fuR state savfng by setting the Check¬ 
point mode to 1; aftematlvely, the user can expfldtty give the ch k p otn t command after particularly 
erne* changes. 


8mu coordinates changes among the experimental databases owned by the members or a 
software project. A user can add a new module only within an experimental database, but Smile 
records the addition in the pubfic database to prevent another user from adding another new 
module with the same name. Similarly, Smile records addRIon of Import Rems m the public 
database, since another user may attempt to delete the Rem In a dNfennt experimental database. 
When the pubic database it locked during a transartton, other actions that affect the public 
dttabaee are blocked until completion of the transaction. Since updats and deport often take 
several minutes, blocked commands time out after thirty seconds and Skill advises the user to 
try again later. This enables users to perform other development actMNet whRe they waR. 


4.4 Change Logs 

When programming teams are large, R It useful to maintain orvlne change logs. Whenever a 
user updates or deposit! the contents of sn experimental database, Smuk prompts for a log entry 
for each modified module. Smile automatically includes the user's name, the time/date, and the 
module name with tho text provided by the user. Users can also append log entries for their 
reserved modules at any time. A user can query the entire tog for a database or only the tog for a 
particular module, and request sntries since s particular date andtor by a particular user. Smile 
prevents tampering with previous tog entrtat, so a lull audit traR of past changes la always avail¬ 
able. 



4.5 Maintenance and ‘Old Coda’ 

Aa software systems become older, the modular structure tends to degenerate, import and ex¬ 
pert lists grow and rarefy shrink, even though an imported Item la no tongar used in the importing 
moctoie and an exported Hem Is no longer used outside the module, or even inside the module 
SMtiE assists users In restructuring old systems by moving items from one module to another and 
adjusts the imports and exports accordingly, by adjusting the Imports and exports throughout the 
database to reflect the actual interconnections determined by cross-references, and by detecting 
u.tused r. jms. 

Smhje provides facilities to bring externally developed old code 1 into a database, so it can assist 
future maintenance and enhancement activities. Smile can also copy modules from one 
database to another. Smile makes It easy to use software maintained outside of a Smile 


*TH» performance problem It recced when Sen runt in a dNtnbuwd worfcmton environment. tea Section 5 
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database: Every module and every database may have a prafcdto, which Ms axtamal flies and 
dsflniitons of outside procedures; th* corra ap ondtog otiject cod* Am and Unix Ibraries art Mad 
m Smu Hbrary Rama. Tha add, remove, and change comm an d * apply to Hbrarias, as do tha 
browsing fscAHaa. Tha namas of necessary fcrerits am given as argumanls to tha build com¬ 
mand to mooqwata than m an executable tystam. Sole haft* usaf* craata new Unix archives 
and ttrariee. R can product a Unix archivt from tha C Rama m tha databasa and can generate a 
singla object coda As that can bs usad as a Rxary outsida Smle or within othar Smle 
(Mabasas. 

8 ImpJsmantetion 

Smu arts originally calad I PC, tor Incramantal Program Constr u ctor, but tha nama was soon 
changad to Saits. A prototypa Impiamantotton was wrtttan In th* Unix shal languag* during 
August 1979; I was usad In Saptambar 1979 to bootstrap to a mor* advancad imptomantttion In 
QC. Thasa two varslons ran m a POP™ 11/70 undsr Unix Varsion 7. 

Sans was soon portsd to a VAX (both 750 and 780) undar Berkeley Unix, whar* R supportad tha 
Intaneiv* OandaK prototypa [10] Imptomantation In i960 and 1981 and tha davatopmant and 
maintenance of tha product bn-quaflty Qnoma anvlronmant starting In 1962. Smle was ported to 
th* Sun Workstation™ In 1964 and to th* MlcroVAX™ workstation In 1985. Th* MIcroVAX ver¬ 
sion to dtotrtbutad by virtu* of th* Mach variant of Unix 4 3 BSD. Th* currant Imptomantation 
consists of 15,000 Unas of QC sourco cod*, which is nvaSabia on request from tha Qandaif 
project at CMU. 


Details 

Although tha original I PC was Imptomantad in tha Unix shaft language, nether I PC nor tha later 
versions oi Smle should b* thought of simply as user shatto. Smu maintains Rs own database 
of aS Information about a software project and provides Is own commands tor carrying out 
davatopmant and maintenance activities: in effect, Smue presents its own model of th* program¬ 
ming process. 

Smu maps rts database onto th* Unix file system in a hierarchical manner. Each database 
corresponds to a directory, which contains a subdirectory for each project, which in turn contains 
• subdirectory tor each module. Each module directory contains two flits Sating tha imports and 
exports, respectively, and four subdirectories, one each for procedures, variables, types, and 
macros. Th* text of each Rani to stored In a separata A*. This mapping to th* fit* system is not 
vistol* to users. Cross-referencing information, status, and other derived attributes are main¬ 
tained In a graph structure. This graph is dumped In binary form to a r»e within th* database to 
persist between invocations of Smile A backup copy of the graph to also maintained, but S both 
ttie original and backup are corrupted, th* graph can be regenerated from tha databasa. 

Smile protects Rs users from operating tystam crashes, which might leave a databasa In an 
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tooonsistsnt sum. Smle automaHcaly checks Ks database at ths beginning of every session: if 
dittoed information such as error messages or object code has been lost. Smu resets status 
info r m a tion to make sure they are raderived. If the most recent session wth this database was 
done using a previous version of Smile ksetf, Smu automatically reformats the graph structure 
and die database and adds default values for any new kinds of attributes. Approximately 30% of 
Smu ‘s source code ie for dteaster recovery end sal repairs. 

Smu hides the Unix He system and Is tools and uttties from Its users, w«h the exception that I 
caHs the users favorite text editor. The defaul text sdRor at CMU is Emacs [9], but a different 
defaut can be substituted at each site. Smu invokes Rnt to detect static semantic errors in 
source code objects, cc to compile modules, and make to generate executable systems. The 
variants of grep support Smuts searches through source text end other objects. 

We have not modified these tods; instead, Smiue automatically tr a nsf o rms objects Into the format 
required by each tooi. For sxampie, Smile combines the Rems of a module into a single Hie !n the 
correct order tor Input to the compfter. This made R easy to port Smu from one version of Unix 
t* another and to use new tools as they became available (eg., Int replaced cc for static seman¬ 
tic analysis in 1982) without these changes being vtsRfe to the users. We believe R would not be 
dKticuR to port Smu to a non-Unix operating system, providing R supplied similar took;; the only 
local tools that ere mandatory are e text editor, e C compSer, and a Inker. 9 


6 Related Systems 

Smu Is similar to knowledge-based programming envi ron ments, advanced programming lan¬ 
guage environments, language-based editors and software engineering environments. In the fol¬ 
lowing paragraphs, we describe the advantages and dfeadvantagss of these systems with 
respect to Smu. 

Knowledge-Bated Environments : Tht Commonllsp Framework (CLF) (8], Refine™ {22] and 
other knowledge-engineering environments can provfoo SMU-flke automation via 
condition/action rules {5]. However, they cannot recognize the sRematfce results of actions, e g., 
the oompder may terminate successfully, producing object code, or unsuccessfully, producing 
error messages. None of these environments support multiple simultaneous users. On the other 
hand. Smile is not extern foie, so It is not as easy to add new kinds of objects and new tools. 

Language Environments : Advanced programming languages such ss intertisp [ 26 ], Loops 
[23] and Smalltalk-80™ [8] Include run time environments that are indistinguishable from single- 
user programming environments. Although they provioc* Smile -Ik* faculties, these are strongly 
tied to the programming language. The implementation of Smile is specific to the GC, but it 
would not be very difficult to reimplement for another conventional programming language. 


*£m*f vartiona of Smu u*ad only to* tool* and utflWa* p rovirtad by Unix, but font wr t ton* alas nduo» *,'*dal tool* 
tor languaga-oriantad programming anvtrpnmant*. That* tool* ar* not ratawvM to t* fa o l l t lai da a ertoa d in toi* papar 
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provided corresponding tools were available. However, language environments can integrate 
debugging facilities with the other tools. 

Lanouaoe-Sased Environments .- 6 Language-based environments add many of the advantages of 
language environments to conventional languages such as Pascal. The Synthesizer [25] and 
Pecan [19] am examples of specific environments, while the Synthesizer Generator [20] and 
GandaJf are systems for generating such environments from formal descriptions. Most language- 
based environments provide advanced user interfaces with menus and pointing devices, and 
perform various activities in response to programmer actions, but they are unable to anticipate 
the potential results of actions and warn users before the damage is done. The practicality of 
these environments is limited, since the entire software system is maintained as a single abstract 
syntax tree; further, I is difficult to incorporate existing programming tools into these environ¬ 
ments. 

Software Engineering Environments : Smile is most similar to Cedar [27], DSEE™ [14], Arcadia 
[24] and other large-scale environments for software development and maintenance. Like Smile, 
these environments provide an interface between programming tools and the user on the one 
hand, and between programming tools and the software database on the other. Such environ¬ 
ments typically provide more advanced version control and project management facilities than 
Smile, but they leave individual programmers to the standard edit/compile/debug cycle supported 
by traditional tools. 

7 Conclusions 

Smile's primary contribution is the apparently intelligent assistance that spans both the activities 
of individual programmers and the coordination of multipie programmers. Smile provides this 
assistance by 

• maintaining all Information about a software project In a database; 

• integrating Unix tools into a new model of development and maintenance that hides 
the particularities of Unix tools; 

• actively participating in the development and maintenance processes by deriving 
data when possible from previously stored Information, automating the invocation of 
these tools and anticipating the consequences of tool processing; 

• Imposing a structure on software development activities that permits it to ‘know’ what 
the programmers are doing at all times, to ‘Infer what they are likely to do next, and 
to ‘judge’ what It can appropriately do for them; 

• recovering from external and internal failures and repairing its databases automati¬ 
cally, making It sufficiently robust and reliable for production use. 

Smile provides this assistance without a knowledgebase of rules describing the software develop¬ 
ment process. Instead, certain 'common sense’ about software development activities has been 


*W# um th* »fm '1anguag*-b«Md snvlronmsnr »ynortymou»ry wfth 1angv*5#-b***d cdtof*, '»tructur»-oriented 
•nvtronm«nr, 'ttnjctur# •drtor b»*«d •nvtronrrwnr, '»ynt»x-<Jtr*cWd •dtof', 
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programmed (firsctfy Into the anvkonnw*, resulting in a production-quality intelligent assistant 
that several projects hava railed on to develop and maintain their software. 
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